Internet web server cache storage and session management system

ABSTRACT

In an Internet implementation, a session is maintained between an Internet web server and a client browser through the use of at least one temporary cache file, preferably saved in a location local to the web server. The web server also interacts with at least one data source, preferably located behind a firewall from the web server. After a cache file is created, it is used to store data received from the client and from the data source, resulting in fewer interactions with the data source. The cache file is saved from working memory before each page is generated and transmitted from the web server, after which the working memory becomes available for other uses. Since each page includes a reference to the cache file, such as in a hidden form field or in the URL of a hyperlink, for example, the session is effectively maintained between pages when the user interacts with the page to generate data that is transmitted from the client to the web server, at which point the web server opens the referenced cache file.

CROSS-REFERENCES TO RELATED APPLICATIONS

[0001] This application is a continuation of U.S. patent applicationSer. No. 09/294,621, filed on Apr. 19, 1999, which was acontinuation-in-part of U.S. patent application Ser. No. 09/203,954,filed on Dec. 2, 1998, and also claimed the benefit of U.S. ProvisionalPatent Application No. 60/106,819, filed Nov. 3, 1998, and U.S.Provisional Patent Application No. 60/110,423, filed Dec. 1, 1998, allof which are incorporated herein by reference in their entireties.

STATEMENT AS TO ANY INVENTION RIGHTS UNDER FEDERALLY SPONSORED RESEARCH

[0002] Not applicable.

BACKGROUND OF THE INVENTION

[0003] The present invention relates generally to the field of sessionmanagement, and more particularly to the field of database sessionmanagement on the Internet, in one embodiment of the present invention.

[0004] The Internet, also referred to as a global computer network, ornetwork of computer networks, includes computers connected through a setof communication protocols known as Transmission ControlProtocol/Internet Protocol (TCP/IP). One popular component of theInternet is the World Wide Web (WWW), or “the web,” which is acollection of resources on servers on the Internet that utilize aHypertext Transfer Protocol (HTTP), which is an application protocolthat provides users access to those resources (often referred to as“pages,” which can be in static or dynamically generated formats,including text, form entry fields, graphics, images, sound, video, etc.)using a Standard Generalized Markup Language (SGML), such as theHypertext Markup Language (HTML), which is an information managementstandard for providing platform-independent and application-independentresources that retain formatting, indexing, and inter-resourcehyperlinking information.

[0005] One reason for the Internet's rapid growth is the introductionand widespread use of web browsers, which are HTML-compliant user clientsoftware programs, or portions of other programs, providing simplegraphical user interface (GUI) access to resources on web servers. Theuse of an HTML-compliant client, such as a web browser, involvesspecification of an address via a Uniform Resource Locator (URL). A URLmay include reference to a static resource or a reference to a softwareprogram on the web server, such as a Common Gateway Interface (CGI)script, as an example, which may interact with a database, or other datasource, to dynamically generate the resource requested by the userthrough the web browser. When a user enters data into fields on a formweb page and then submits that data, the browser communicates that datato the web server, as part of or accompanying the URL transmitted fromthe browser to the web server, which may then be used by a CGI script ininteracting with the data source to generate the next resource for theuser.

[0006] Like many network protocols, HTTP uses a client-server model. AnHTTP client, such as a user browser, opens a connection and sends arequest message to an HTTP server, such as a web server, which thenreturns a response message, usually containing the resource that wasrequested. After delivering the response, the web server closes theconnection, which makes HTTP a stateless protocol, i.e. not maintainingany connection information between transactions. In other words, HTTPdoes not practically provide for maintaining a “session” as a userrequests and interacts with various resources. Because of transfer speedlimitations of the Internet, users can become frustrated waiting onlarge resources to slowly download to user browsers. In addition, verylarge resources can be confusing to many users.

[0007] Consequently, designers of web resources tend to break largerresources into multiple smaller resources to speed download times foreach of the smaller resources, as well as to present users withresources that are more manageable and understandable. However, sinceHTTP is a stateless protocol, designers needed to develop a method forconveniently maintaining a session between user interactions with thedifferent resources. One method of addressing this problem has becomeknown as “cutting a cookie” on a user's computer, which often includesthe web server reading and writing certain information to a user's harddrive in files called “cookies.” Since many users do not allow suchmanipulation of their hard drives, and since the amount of data neededin some sessions would make this solution unworkable, the use of cookiesdoes not fully address this problem. Other methods of attempting toefficiently maintain a session include inserting information as hiddenform fields or part of the return URL in the resources, or web pages,themselves. As with cookies, some sessions may require more data thanwould be practical to include in such hidden form fields or URLs. Inaddition, such methods may expose sensitive data to unauthorized access.

[0008] Yet another attempt at effectively solving this problem ofefficiently maintaining a session includes using the primary data sourceused in dynamically generating the resources. In other words, the datasource would be accessed every time the web server receives datasubmitted by a user and one of the many smaller resources is generated.Unfortunately, such a method is often a rather inefficient use of a verybusy data source and can lead to higher costs and complexity for datasources supporting web resources. Furthermore, if the data source is notlocated on the web server, additional delay may be introduced. On theother hand, locating the data source on the web server could create alarger risk of unauthorized access.

[0009] There is, therefore, a need for a system for addressing these andother related and unrelated problems.

SUMMARY OF THE INVENTION

[0010] In addition to other implementations, in an Internetimplementation, a session is maintained between an Internet web serverand a client browser through the use of at least one temporary cachefile, preferably saved in a location local to the web server. The webserver also interacts with at least one data source, preferably locatedbehind a firewall from the web server. After a cache file is created, itis used to store data received from the client and from the data source,resulting in fewer interactions with the data source. The cache file issaved from working memory before each page is generated and transmittedfrom the web server, after which the working memory becomes availablefor other uses. Since each page includes a reference to the cache file,such as in a hidden form field or in the URL of a hyperlink, forexample, the session is effectively maintained between pages when theuser interacts with the page to generate data that is transmitted fromthe client to the web server, at which point the web server opens thereferenced cache file.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0011] The accompanying drawings incorporated in and forming a part ofthe specification illustrate several aspects of the present invention,and together with the description, serve to explain the principles ofthe invention.

[0012]FIG. 1 is a block diagram illustrating various acceptableimplementations of components associated with the present invention, inaccordance with various embodiments of the present invention.

[0013]FIG. 2 is a flow chart representation of selected basic genericsteps of one embodiment of the present invention.

[0014] FIGS. 3-7 are flow chart representations of steps performed inone implementation of one embodiment of the present invention.

[0015] Reference will now be made in detail to the description of theinvention as illustrated in the drawings. While the invention will bedescribed in connection with these drawings, there is no intent to limitit to the embodiments disclosed therein.

DETAILED DESCRIPTION OF THE INVENTION

[0016] Turning now to the drawings, wherein like reference numeralsdesignate corresponding parts throughout the drawings, FIG. 1 is a blockdiagram illustrating various acceptable implementations of componentsassociated with a web server cache storage and session management system10 of the present invention, in accordance with various embodiments ofthe present invention. A web server 20 is shown connected to workingmemory 21, common gateway interface (CGI) programming 22, static pages24, and cache files 26. A firewall 30 is shown connecting the web server20 to a data source 31, represented as a data server 32 connected to adatabase 34. Another firewall 34 is shown connecting the web server 20to an Internet service provider (ISP) 42, which is connected to Internet44. Another ISP 45 is shown connecting a firewall 46 to a data source47, including data server 48 and database 50, to the Internet 44. A userbrowser 52 is shown connected to the Internet 44 through an ISP 54, anda user browser 56 is connected through a local area network (LAN) 58 andan ISP 60 to the Internet. A user browser 62 is shown connected directlyto the web server 20. Except for the web server 20, each of the elementsshown in FIG. 1 are representative of multiple similarly situatedcomponents. In addition, except to the extent discussed herein regardingthe functionality of the present invention, the elements shown in FIG. 1essentially include conventional hardware and software components, aswould be understood by those reasonably skilled in the art of thepresent invention. For example, a user browser is understood to includevarious types of conventional browsing functionality, including, forexample, a browser software program running on a personal computer, aswell as browser functionality incorporated into an operating system orfunctioning with other hardware, such as a handheld device, atelevision, etc.

[0017] As stated above, FIG. 1 illustrates various acceptableimplementations of the present invention. For example, oneimplementation includes user browser 52 operating through ISP 54, theInternet 44, ISP 42, and firewall 40 to interact with the web server 20and accompanying elements 21, 22, 24, and 26, which interact with dataserver 32 and database 34 through firewall 30. Another implementationincludes the previous implementation with the addition of elements 45,46, 48 and 50. Still other implementations include providing access toweb server 20 for user browsers 56 through LAN 58, ISP 60, and Internet44, as well as directly to user browser 62. Still other implementationsomit the Internet entirely, including only user browser 62 (and othersimilarly situated browsers, as discussed above), web server 20 withaccompanying elements 21, 22, 24, and 26, as well as firewall 30, dataserver 32, and database 34. Still other implementations include omittingfirewall 30 and combining web server 20 with data server 32, makingdatabase 34 directly accessible by web server 20. Also, the linesbetween the web server 20 and the other elements should be understood toinclude direct local connections, local area network connections, andwide area network connections. For example, although not shown, thecache files 26 are located across the Internet 44 from the web server 20in other implementations. Of course, one ISP might be used by multipleelements shown in FIG. 1, and the web server 20 is located within an ISPin some embodiments. Firewalls are also variable in other embodiments,including the omission of one or more firewalls, as well as the additionof firewalls, such as between the web server 20 and the cache files 26.In addition, other embodiments include other ordinarily statelessservers 20 besides those that qualify as “web” servers. Of course, thesestatements describing other embodiments and implementations of thepresent invention are not intended to be comprehensive.

[0018] In one example implementation, the CGI programming 22, staticpages 24 and cache files 26 are normally stored in non-volatile memory,such as one or more local hard drives, until executed or utilized inworking memory 21, which includes, as an example, standard random accessmemory (RAM). Of course, web server 20 also preferably includes otherconventional elements, such as a high performance microprocessor,networking capabilities, internal bus systems, a power supply, anoperating system, input/output devices such as a keyboard, a mouse, ascreen, etc., as would be understood by those reasonably skilled in theart of the present invention. However, the elements of the presentinvention can be implemented in any combination of software andfirmware. In one preferred embodiment, the system 10 is implemented insoftware that is stored in a memory and that is executed by a suitableinstruction execution system. Nonetheless, the system 10, which includesordered listings of executable instructions for implementing logicalfunctions, can be embodied in any computer-readable medium for use by orin connection with an instruction execution system, apparatus, ordevice, such as a computer-based system, processor-containing system, orother system that can fetch the instructions from the instructionexecution system, apparatus, or device and execute the instructions. Inthe context of this document, a “computer-readable medium” can be anymeans that can contain, store, communicate, propagate, or transport theprogram for use by or in connection with the instruction executionsystem, apparatus, or device. The computer readable medium can be, forexample but not limited to, an electronic, magnetic, optical,electromagnetic, infrared, or semiconductor system, apparatus, device,or propagation medium. More specific examples (a non-exhaustive list) ofthe computer-readable medium would include the following: an electricalconnection (electronic) having one or more wires, a portable computerdiskette (magnetic), a random access memory (RAM) (magnetic), aread-only memory (ROM) (magnetic), an erasable programmable read-onlymemory (EPROM or Flash memory) (magnetic), an optical fiber (optical),and a portable compact disc read-only memory (CDROM) (optical). Notethat the computer-readable medium could even be paper or anothersuitable medium upon which the program is printed, as the program can beelectronically captured, via for instance optical scanning of the paperor other medium, then compiled, interpreted or otherwise processed in asuitable manner if necessary, and then stored in a computer memory.

[0019]FIG. 2 is a flow chart representation of selected basic genericsteps 200 of one embodiment of the present invention. With reference toFIG. 1 and FIG. 2, the steps 200 are from the perspective of the webserver 20 running one or more CGI programs 22. While there are manyacceptable implementations of the elements of FIG. 1 as discussed above,only one implementation will generally be discussed hereafter, merelyfor purposes of clarity. Thus, based on the above discussions,applicability of the following functions to other implementations wouldbe understood by those reasonably skilled in the art of the presentinvention. After data is received at the web server 20 from the userbrowser 52 (step 202), the web server 20 utilizes that data tocommunicate with and request data from the data source 31 (step 204).After data is received from the data source 31 (step 206), the webserver 20 saves the data from the data source 31 and data from the userbrowser 52 in a cache file 26 (step 208). Subsequently, the web server20 generates and outputs a resource, such as an HTML web page, to theuser browser 52, wherein the resource includes a reference (such as afilename or ID number saved as a hidden form field or hyperlink URLparameter, as examples) to the particular saved cache file 26 related tothat session (step 210). After a user interacts with the newly generatedresource, the web server 20 receives additional data from the userbrowser 52, including the reference to the cache file 26 (step 212).Again under CGI programming 22 control, the web server 20 opens,updates, and saves the referenced cache file 26 responsive to the datareceived from the user browser 52 (step 214). If the CGI programming 22determines that the data source 31 should be accessed for reporting dataor retrieving additional data (step 216), processing continues with step204. Otherwise, processing continues with step 210 without interactionwith the data source 31. Of course, the generic loop shown in FIG. 2 isultimately ended normally when an application process is finished orthrough failure of a user to respond to a resource, such as betweensteps 210 and 212. Also, another process, a cache file deleter, notshown, is continually executed on web server 20 for deleting cache files26 experiencing no activity within a defined period of time, rangingfrom minutes to weeks, as examples, depending on particularimplementations. During that time, a user may be able to come back tothe system and retrieve automatically saved work that was saved in thecache file.

[0020] Refer now to FIGS. 3-7, which are flow chart representations ofsteps performed in one implementation of one embodiment of the presentinvention. One example of a service that generally follows the steps ofFIGS. 3-7 is the automobile insurance quote request process described inU.S. patent application Ser. No. 09/203,954, filed on Dec. 2, 1998,which is incorporated herein by reference in its entirety. Of course,the disclosure of this example is not intended to limit theapplicability of the principles of the present invention since they areapplicable to a multitude of particular implementations. FIG. 3 of thepresent application shows a process starting (step 302) with the webserver 20 receiving a request from a user for a login page (step 304).Such a request is typically transmitted to the web server 20 from a userbrowser 52 after a user selects a hyperlink from another page, in whichcase the URL arriving at the web server 20 may include additionalvariables that can be used in designing the login page that issubsequently sent to the user (step 306). Of course, the login page maysimply be displayed when a user types in a home page URL or otheraddress with no additional parameters. According to this particularexample, the login page includes username and password form fields to befilled-in and submitted by the user, after which point they are receivedby the web server 20 (step 308). As is understood by those reasonablyskilled in the art of the present invention, form fields may be reportedto a web server 20 through a “post” or “get” technique. For purposes ofthis disclosure, the data that is returned is referred to herein as“command line” data since it comes from the user browser with the URL,or immediately thereafter. The “submit” button, or its equivalent, onthe login page is set to activate one of the CGI programs 22, referredto as “login CGI” (step 310). One of the first actions of login CGI isto allocate a portion of working memory 21 for temporary use by loginCGI for that particular user, and then to copy into that portion ofworking memory 21 the command line data received from the user, as wellas standard cache information. The standard cache information isaccessed from a file (not shown) in web server 20 which includesglobally relevant information applicable to all CGI programs 22, such asstandard names of data sources, data source port numbers, style & errordirectories, system status, etc.

[0021] Subsequently, login CGI attempts to locally validate the logininformation (step 314), such as by making sure the correct number andtypes of digits were entered by the user in the username and passwordfields. If the information does not pass local validation processing,the login page is re-sent to the user with an error message (not shown),and processing continues back at step 306. If the information passeslocal validation processing, the information is sent to the data source31 as part of a request (or transaction) for additional data regardingthat user (step 316). Building a transaction with a data source 31includes using data from the standard cache information, as well asadditional information about a particular user, to build the request. Ifdata is not received from the data source 31 after the web server 20waits (step 318) for a defined period of time response, a system errorpage is generated and transmitted to the user (not shown). However, ifdata is received from the data source 31 within that period of time, thedata is parsed and stored in the working memory cache data of workingmemory 21 along with the previously stored standard information andcommand line information received from the user (step 320). Datareceived from the data source 31 includes, as examples, withoutlimitation and among others, a session identification (session ID) thatis used to identify the current session, an indication of whether theuser is a valid user, options available to that particular user fordisplay on an upcoming menu page, graphical style indications andavailable images for formatting the upcoming menu page, any results ofprevious processing now available to the user since a previous visit,etc. If the login information does not correspond to a registered user,the login screen is again sent with an error message (not shown), asdiscussed above in the case that the login information does not passlocal validation. Otherwise, operation proceeds as shown, and theworking memory cache data, except for the standard cache information, issaved in a file, using the session ID as the cache ID and name of thefile (step 322). Of course, other embodiments of the present inventioninclude using any name for the cache file, including one created by theweb server 20, rather than by the data source 31. In one embodiment, thecache file is a data structure that, in one example of an acceptableimplementation, includes various sections, including a cache ID, fielddefinitions, validation routines, validation errors, error handlers, andlog messages that keep track of the pages viewed by a user. Each fielddefinition entry in the cache includes a tag, a value, a type, and adescription. A corprate CGI program of CGI programs 22 is then called bythe login CGI program, including passing the cache ID as a parameter tothe corprate CGI program (step 324, 326). After that point, that portionof the working memory 21 becomes free for use by CGI programs 22. Thus,while no page has yet been sent to the user, the cache file has beensaved, such as to non-volatile memory, and the session is maintained bya call between CGI programs.

[0022] Referring now to FIG. 4, after beginning operation (step 402),the corporate CGI accesses the stored cache file (step 404). In this andother references to steps of accessing the cache file, it should beunderstood that a portion of working memory 21 is again allocated, andthe programming copies into that memory the stored cache file referencedby the cache ID, as well as any data arriving on the command line to theinvoke the programming, as well as the standard cache informationdiscussed above. The command line data would replace any differingvalues from the stored cache file. As discussed below, one embodiment ofthe present invention includes the creation and maintenance of a sessioncache file, as well as sub-session, or child, cache files. When a childcache is created, such as would be useful during one of a variety ofcomplex services, or requests, that are available to a user, the cacheID of that child cache is saved as a child cache ID in the session cache(i.e., the only cache created at this point). Since there is no need fora child cache at this point in the processing, the corprate CGI sets thechild cache ID field in the session cache (step 406), and then saves thecache file (step 408). Subsequently, a frame definition page isgenerated and sent to the user (step 410) before a menu CGI is calledfor building a menu frame (step 412), with the cache ID being passed tothe menu CGI. As will be seen below, one of the reasons that thecorporate CGI is separated from the login CGI is to be able toconveniently jump to that page creation point without going through theprevious login steps of the login CGI. Other CGI programs (not shown)are also called to build other previously defined frames (step 410), butonly the menu CGI is shown for clarity.

[0023] When the menu CGI starts, as with other CGI programs, the cachefile is again accessed and loaded into a new portion of working memory21, which, as discussed above, includes loading the standard cacheinformation and any command line data (step 414). Subsequently, thecache is again saved (step 416) before the menu frame is built and sentto the user, including menu items configured as hyperlinks calling afilter CGI with the cache ID and a request to have a notification sentto the data source 31 (step 418). In this implementation, the generalpurpose filter CGI program makes substitutions into a standard templatefiles, wherein the URL calling the filter CGI specifies the file to bemanipulated and the values to use in the substitutions, as well aswhether to use a particular cache file for those values. Filter CGI canalso be used for simple procedural logic processing, such that, forexample, if-then statements in a file to be filtered can direct thefiltering. In addition, filter CGI can be directed to execute atransaction with the data source, such as reporting the occurrence of auser executing a particular hyperlink, as is the case in the presentembodiment when a user selects one of the menu items displayed to theuser. Of course, other embodiments include individual scripts used inplace of filter CGI. When user data is received (step 420), filter CGIis initiated according to the hyperlink selected by the user, whichresults in the reporting transaction to the data source 31, as discussedabove, as well as the creation and sending to the user of aninstructions page for the selected service (step 422). In thisimplementation, the instructions page includes a “start” hyperlink atthe bottom of the instructions page, and the hyperlink includes thecache ID and a call to a large CGI program, referred to as w11 CGI.Except to any extent necessary for the notification transaction sent tothe data source 31, the filter CGI does not access the cache file, thusit is not loaded into working memory and re-saved for the generation ofthe instructions page. This shows how the filter CGI can be used forpresenting largely static pages 24 since only a small amount of dataneeds to be substituted, such as inserting the proper cache ID in the“start” hyperlink. Subsequently, if the user selects the “start”hyperlink, the web server 20 receives an indication of that selection,including the cache ID, and the w11 CGI is initiated (steps 426, 428).The w11 CGI is specific to a particular request or service provided bythe system 10 of the present invention, according to one embodiment.

[0024] Referring now to FIG. 5, after w11 CGI begins execution (step502), it accesses the cache file (step 504) as other scripts have donepreviously, including loading the referenced cache file into a workingmemory, along with standard cache information. At that point, a requestID transaction is built and transmitted to the data source 31 (step 506)in which the data source 31 is asked for a new request ID for assigningto this particular request. The w11 CGI is specific to a particular typeof request, or service, provided by the system 10 of the presentinvention, according to one embodiment. After the request ID is receivedby the web server 20 (step 508), it is inserted as the value of thechild cache ID field in the cache data currently stored in the workingmemory, which is then saved as a cache file (step 510). After thatpoint, that file can be referred to as the session cache file.Subsequently, the working memory cache data is edited to change thecache ID from the session cache ID to the new request ID supplied fromthe data source 31, and the child cache ID field is set to NULL (step512). As with the original cache ID, this request ID can be generated bythe web server 20 or other source in other embodiments of the presentinvention. Names for files on the web server 20 to receive data to berequested from the data source 31 are then defined and stored in theworking cache memory (step 514), and additional transactions are builtand transmitted to the data source 31 to request additional information(step 516). Subsequently, child processes are created to wait for theresulting data from the data source 31 and then store that data in filesaccording to the previously defined filenames (step 518). These childprocesses continue living past this particular execution of w11 CGI, aswell as past the creation and transmission of a page to a user, as shownbelow. Subsequently, the working memory cache data is saved in a newcache file according to the new cache ID (step 520). An additionalinstruction page is then generated and sent to the user (step 522),including hidden form fields with data to be returned to the web server20 when the user submits the form, including cache ID, page ID, and areference to the w11 CGI code that generated the page. Since the w11 CGIis a large script handling results from multiple types of pages, itneeds direction regarding which code section to execute for particulardata, for which the page ID is used. Also, in handling errors resultingfrom data entered for a particular page, the w11 CGI references the codethat generated the page, which is another parameter that is passed backto it with the submission of a form from the user. In addition, thoughnot shown, a restart ID is also often passed back and forth for use withthe page ID for subsequent pages to help return the correct page to auser when a user selects “back” or a “reload” on the browser sinceframes often prevent the UTRL from containing the proper information toaccomplish the correct reload or return to a previous page. Finally, thew11 CGI terminates (step 524) while the child processes wait for therequested data to be received from the data source 31.

[0025] Referring now to FIG. 6, after starting (step 602), a user submitindication is received at the web server 20 along with the hidden formfields discussed above (step 604). As before, the cache file is accessed(step 606), and w11 CGI is executed at the appropriate segment for thepage just shown to the user, which in this case, was simply anotherinstruction page with a “continue” button operating as a form submitfunction. Since enough time should have passed for the data source 31 toreply to the previous transactions being monitored in the background bythe child processes discussed above, the respective files should havebeen created with data from the data source 31. That data is then parsedand stored in the working memory cache (step 610), which is then editedby defining the form elements for the next page to be sent to the user,including data validation and error handling information. The datavalidation information includes local validation rules (e.g., number ofcharacters, type of characters, format, etc.) and references to otherprogramming code segments to handle more complicated validationprocedures. Error handling information includes references to codesegments for controlling how errors are handled and subsequentlydisplayed to users. The data from the data source 31 is used as defaultvalues for any fields in which the user may entered previously entereddata that was then stored in the data source 31, maybe even from otherservices or requests the user may previously have executed.Subsequently, the cache file is saved (step 614), and a page isgenerated and set to the user (step 616). That page includes displayedform fields for receiving input from a user and hidden form fieldsreferencing the cache ID, page ID, reference to the code that generatedthe page, reference to any sequence numbers for pages used in sequentialrepetition, and optionally a restart ID (not shown) as necessary, asdiscussed above. Then, w11 CGI terminates (step 618) until a usersubmission is received, including hidden form field data and responsesto displayed form fields (steps 620, 622).

[0026] With reference to FIG. 7, after beginning (step 702), w11 CGI isagain executed in response to the data received from the user (step 704)and in the location corresponding to the page (page ID) that producedthe data returning from the user. The cache file is accessed and updatedwith the data from the user (also referred to herein as the command linedata) (step 706). Local validation is then attempted (step 708), basedupon the rules and any referenced validation code segments stored in theworking memory cache data. If the data is not locally valid (step 710),error messages are stored in the working memory cache data (step 712) sothat system administrators can help users who get stuck. Then,appropriate error handling code is executed (step 714) for controllinghow errors will be reported to the user, as discussed above. The cachefile is saved (step 716), and the page that generated the errors isre-sent to the user with the appropriate error messages (steps 718,720), after which processing continues as before when the page was sentto the user (step 720 and steps 652, 618 in FIG. 6). If the data fromthe user was validated (step 710), w11 CGI determines if informationshould be reported to the data source 31 (step 722). If not, processingcontinues to send another page to the user (step 724 and steps 650, 612in FIG. 6). Otherwise, a reporting transaction is generated andtransmitted to the data source 31 (step 726). If there are more pages todisplay to the user, processing continues to display the next page (step724 and steps 650, 612 in FIG. 6). Otherwise, the cache file is saved(step 730), and corprate CGI is called, with the session ID being usedas the new cache ID (step 732), and processing continues with corprateCGI (steps 732, 734 and steps 402, 404 in FIG. 4). Eventually, the childcache file is deleted, and thus, the child cache was used during therequest to store a large amount of additional data that was not neededin the session cache file.

[0027] In concluding the detailed description, it should be noted thatit will be obvious to those skilled in the art that many variations andmodifications can be made to the preferred embodiment withoutsubstantially departing from the principles of the present invention.All such variations and modifications are intended to be included hereinwithin the scope of the present invention, as set forth in the followingclaims.

We claim:
 1. A server method for maintaining a session between a clientand a server, said method comprising steps of: transmitting a resourceto a client from a server, wherein the resource includes a reference toa temporary cache file; receiving data from the client responsive to theresource, wherein the data includes a reference to the temporary cachefile; opening the temporary cache file based upon the reference includedin the data received from the client; and storing at least a portion ofthe data received from the client in the temporary cache file.
 2. Themethod of claim 1, wherein the temporary cache file is stored locally onthe server.
 3. The method of claim 1, further comprising steps ofcommunicating with a data source and storing data from the data sourcein the temporary cache file.
 4. The method of claim 3, wherein thecommunicating step includes communicating through a network with thedata source.
 5. The method of claim 4, wherein the communicating stepincludes communicating through a firewall with the data source.
 6. Themethod of claim 3, wherein the transmitting step includes transmittingdata received from the data source to the client.
 7. The method of claim3, wherein the communicating step includes requesting data from the datasource, initiating a process to both wait to receive the data from thedata source and write the received data to a file with a defined name,and writing the defined file name into the temporary cache file, whereinthe communicating step occurs prior to the transmitting step, except forthe receiving of the data from the data source and the writing of thereceived data to the file with the defined name.
 8. The method of claim1, wherein the storing step includes updating information in thetemporary cache file based upon data received from the client.
 9. Themethod of claim 1, further comprising steps of communicating with aplurality of data sources and storing data from the plurality of datasources in the temporary cache file.
 10. The method of claim 1, furthercomprising steps of receiving a session creation request from a client,communicating with a data source responsive to receiving the sessioncreation request, receiving data from the data source, and saving thetemporary cache file with data from the session creation request anddata from the data source.
 11. The method of claim 10, furthercomprising steps of transmitting at least one additional resource to theclient based upon the temporary cache file before communicating againwith the data source.
 12. The method of claim 10, further comprisingsteps of transmitting a plurality of additional resources to the clientbased upon the temporary cache file before communicating again with thedata source.
 13. The method of claim 10, wherein the session creationrequest includes login information from a user, and further includingtransmitting a login resource to a client prior to receiving the sessioncreation request.
 14. The method of claim 1, further comprising a stepof deleting the temporary cache file after the passing of a definedperiod of time after any data is received from the client.
 15. Themethod of claim 14, wherein the defined period of time is no more than afew hours.
 16. The method of claim 14, wherein the defined period oftime is at least one week.
 17. The method of claim 1, wherein the serverincludes a web server, the client includes a user browser, the resourceincludes an HTML page, and the reference to the temporary cache fileincludes a hidden form field.
 18. The method of claim 1, furthercomprising a step of creating a plurality of temporary cache files basedupon data received from the client, wherein said plurality of temporarycache files include a session cache file and at least one sub-sessioncache file to which the session cache file includes a pointer.
 19. Themethod of claim 1, further comprising a step of validating data receivedfrom the client using validation rules saved in the temporary cachefile.
 20. A server cache system embodied in a storage medium formaintaining a session between a server and a client, said server cachesystem comprising: a resource transmitter configured to transmit aresource to a client, wherein the resource includes a reference to atemporary cache file; a client data receiver configured to receive datafrom the client responsive to the resource, wherein the data includes areference to the temporary cache file; and a temporary cache fileprocessor configured to open the temporary cache file based upon thereference included in the data received from the client and to store atleast a portion of the data received from the client in the temporarycache file.
 21. The system of claim 20, wherein the temporary cache fileis stored locally on the server.
 22. The system of claim 20, furthercomprising a data source communicator configured to communicate with adata source and store data from the data source in the temporary cachefile.
 23. The system of claim 22, wherein the data source is connectedto the server through a network.
 24. The system of claim 23, wherein afirewall separates the data source from the server.
 25. The system ofclaim 22, wherein the resource transmitter is further configured totransmit data received from the data source to the client.
 26. Thesystem of claim 22, wherein the data source communicator is furtherconfigured to request data from the data source, initiate a process toboth wait to receive the data from the data source and write thereceived data to a file with a defined name, and write the defined filename into the temporary cache file, wherein the data source communicatoris configured to operate prior to the transmission of the resource tothe client, except for the receiving of the data from the data sourceand the writing of the received data to the file with the defined name.27. The system of claim 20, wherein the temporary cache file process isfurther configured to updating information in the temporary cache filebased upon data received from the client.
 28. The system of claim 20,further including a data source communicator configured to communicatewith a plurality of data sources and store data from the plurality ofdata sources in the temporary cache file.
 29. The system of claim 20,further comprising a session creation request receiver configured toreceive a session creation request from a client and a data sourcecommunicator configured to communicate with a data source responsive tothe session creation request receiver receiving a session creationrequest from the client, wherein the temporary cache file processor isfurther configured to save data from the data source in the temporarycache file.
 30. The system of claim 29, wherein the resource transmitteris further configured to transmit at least one additional resource tothe client based upon the temporary cache file before the data sourcecommunicator again communicates with the data source.
 31. The system ofclaim 29, wherein the resource transmitter is further configured totransmit a plurality of additional resources to the client based uponthe temporary cache file before the data source communicator againcommunicates with the data source.
 32. The system of claim 29, whereinthe session creation request includes login information from a user, andfurther including a login resource transmitter configured to transmit alogin resource to a client prior to the session creation requestreceiver receiving the session creation request.
 33. The system of claim20, further including a temporary cache file deleter configured todelete the temporary cache file after the passing of a defined period oftime after any data is received from the client by the client datareceiver.
 34. The system of claim 33, wherein the defined period of timeis no more than a few hours.
 35. The system of claim 33, wherein thedefined period of time is at least one week.
 36. The system of claim 20,wherein the server includes a web server, the client includes a userbrowser, the resource includes an HTML page, and the reference to thetemporary cache file includes a hidden form field.
 37. The system ofclaim 20, wherein said temporary cache file processor is configured tocreate a plurality of temporary cache files based upon data receivedfrom the client by the client data receiver, wherein said plurality oftemporary cache files include a session cache file and at least onesub-session cache file to which the session cache file includes apointer.
 38. The system of claim 20, wherein said temporary cache fileprocessor is further configured to store validation rules in saidtemporary cache file according to which the data received from theclient is validated.